home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload Trio 2 / Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO / dir24 / aprs308.zip / README.BBS < prev    next >
File List  |  1993-09-27  |  7KB  |  108 lines
  1.        USING PBBS's AND INCLUDING APRS PROTOCOLS IN BBS and NODE SOFTWARE
  2.  
  3.     One thing we have learned in maintaining an operational APRS net on 145.79,
  4. is that it is very useful for all stations to include in the comment field of
  5. their position report the address of their home BBS!  Then any station on the
  6. APRS frequency immediately learns how to send that station a lengthy packet
  7. message.  If your TNC supports an internal BBS, it is also useful to leave it
  8. on and include its unique address or SSID in your comment field so that stations
  9. can access your PBBS even while you are running APRS!  A few stations sending
  10. keyboard messages into a PBBS on the APRS frequency is not objectionable since
  11. the number of packets are small and at typing speed.  I encourage all stations
  12. to operate their own PBBS maildrops on the APRS frequency; but please do not
  13. use the PBBS's to post messages for others who must read the message over the
  14. air.  All stations should avoid any other general computer to computer exchanges
  15. which would block the frequency for large blocks of time.
  16.  
  17.     The remainder of this file is intended for BBS SYSOPS and the writers of
  18. BBS and NODE software.  Please consider the following advantages to including
  19. APRS protocols in your station operation.  Since APRS allows stations to see
  20. the network topology in real-time, it is ideal for determining the locations
  21. of all neighboring BBS's and NODES.  If BBS's and NODES simply included either
  22. the LAT/LONG or GridSquare in a periodic UI frame, all users could see where
  23. the system is located.  For permanent  sites such as BBS's and NODES, this
  24. beacon could probably be transmitted once every hour or so.  As of APRS version
  25. 2.08 the !LAT/LONG format can be placed anywhere in the BText.  This was to
  26. accommodate THENET Nodes and some BBS software where the beginning of the BText
  27. is pre-loaded with something already and the !LAT/LONG can only be appended to
  28. the end.  The exact format of the UI frame should be as follows:
  29.  
  30.     BBSXX>APRS:!DDMM.xxN/DDDMM.xxW[comments as desired to end of line
  31.     BBSXX>APRS:[GRidsq]Comments to end of line
  32.  
  33.     For BBS code writers, this process can be enhanced by making the BBS respond
  34. to APRS Query packets.  One of these packets is transmitted whenever an APRS
  35. station initializes his program.  On receipt of an APRS Query packet, all
  36. stations on frequency set a two minute random number timer and respond sometime
  37. in the next 2 minutes with their location.  This way, any APRS station can
  38. obtain the location of all stations on the frequency soon after comming on
  39. frequency.  The format of the APRS Query packet is W4XYZ>APRS:?APRS?.  By
  40. including the code in NODE and BBS software to respond to APRS Querys, the
  41. periodicity of the APRS position beacon can easily be set quite infrequently
  42. since stations can request the BBS position at any time.  For those concerned
  43. with physical security, the grid square position report can be used which is
  44. ambiguous to 3 miles or so instead of the LAT/LONG posit accurrate to 60 feet.
  45.  
  46.     I have one other request to BBS SYSOPS.  Since APRS contains a BEACON
  47. parser to display to users all BEACONS heard on frequency, this is an excellent
  48. way for stations to capture MAIL-FOR beacons.  APRS stations simply call up
  49. their LATEST BEACONS display and see if there are any BBS's reporting mail for
  50. them.  Unfortunately, the parsing algorithm in APRS only recognizes BText which
  51. occurs on the same line as the packet header.  MAIL-FOR which is listed on a
  52. second line after the header do not show up in the APRS system.   For this
  53. reason I would like to request BBS SYSOPS to modify their MAIL-FOR beacons to
  54. keep the beginning of the MAIL-FOR list on the same line as the packet header.
  55. By allowing APRS stations to see mail lists without even logging on, you are
  56. helping reduce congestion on the channel.  Presently, most stations do not see
  57. MAIL-FOR beacons because they scroll off the screen too rapidly.  APRS grabs
  58. all BEACONS heard and retains them.
  59.  
  60.      Please play with the APRS software and load some of the backup and
  61. demonstration files included.  I'm sure you will find APRS to be an exciting
  62. new capability for packet radio which can make packet radio much more responsive
  63. in real-time communications.
  64.  
  65.      Finally, ambitious code writers could add code in their BBS's to capture
  66. all APRS position reports heard on frequency.  These reports could be retained
  67. in a file and be made available to local users.  One of these files, if
  68. downloaded, can be loaded by APRS users to display the locations of all stations
  69. ever heard on the frequency!  Talk about preparations for emergency comms!
  70.  
  71. BBS FORWARDED POSITION REPORTS:  Since we already have a worldwide packet
  72. network of BBS's which have the ability to forward a packet message anywhere
  73. in the country, I would like to see a standard message format built which would
  74. permit a mobile, roving packet station to report his location back to his home
  75. BBS.  Imagine that this mobile station simply posts a message on any nearby BBS
  76. which contains his position and the routing for his home BBS.  That packet
  77. message would be forwarded via the normal BBS network and arrive at the intended
  78. destination whereupon the destination BBS would in turn send out an APRS beacon
  79. reporting that unit's position even if he was thousands of miles away and on
  80. the road!  All of his buddies (or his wife) would see on their home computers
  81. his latest position automatically which was actually relayed through the packet
  82. BBS network.  As with any APRS position report, the beacon periodicity would
  83. decay from 10 minutes to once every few hours as the position report got older.
  84. The format for such a position report for WB4APR might be as follows:
  85.  
  86. SEND:    SP APRS @ W3IWI.MD.USA                   Send command with Routing
  87. Subj:    !3858.11N/07629.11W/040/010              LAT/LONG/CSE/SPD
  88. Msg:     Be home at 1200 Saturday.                Comment field up to 40 chars
  89.          /EX
  90.  
  91. On receipt of such a message, the receiving BBS (W3IWI) would form an APRS
  92. station reporting UI frame and transmit it periodically as follows:
  93.  
  94. W3IWI>APRS:WB4APR   @051937/3858.11N/07629.11W/040/010/Be home at 1200 Saturday
  95.  
  96. As with all APRS packets, this packet would be transmitted once, then 16 seconds
  97. later, then 32 seconds later, then a minute later, and so on.  This doubling
  98. ot the packet period after each transmission decays very repaidly to only 6
  99. packets in the first 10 minutes, 3 more in the next hour and only 3 more in an
  100. entire 24 hours!  Since the packet took hours to get to the BBS in the first
  101. place, it might be more appropriate to start off with an initial period of one
  102. or two minutes.  This is not such a load!  This would only be 9 packets in the
  103. first day and only 1 in the second!  When the period is greater than 24 hours,
  104. the message is deleted from the system. People on the road reporting home would
  105. probably send a new message every 24 hours anyway.
  106.  
  107.  
  108.